47_More SPI Progress
I was going to try to build the a PCB today for our motor control design so that we could test the actual surface-mount chips we’ll be using. Previously we’ve used similar DIP package chips available in the lab stockrooms. However, I found out that the SPI module was not actually receiving the data from the ADC; so I spent more time trying to fix that before moving on.
Although the converted values were visible on the SDI1 pin (SPI1 module input pin / ADC output), the SPI modules receive buffer flag was never setting (SPIRBF = 1). This meant that the receive buffer was never actually receiving the bits. I thought there were several possible causes for this:
- IC pin not connected to header socket
- SPI_read() function not reading at correct time
- physical SDI1 pin is being hogged by some other module as an output, preventing SPI1 from using it as an input
I eliminated the first possibility by, checking that the physical IC pin had a connection to the header pin. After that, I read more about the process of receiving data in the SPI module. There's two virtual SPI buffers [SPIxRXB (receive buffer) & SPIxTXB (transmit buffer)] and one actual buffer (SPIxBUF) as shown in Figure 1. SPIxBUF shares both transmit and receive bits at certain times. Any time data is written to SPIxBUF, bits are moved from SPIxTXB (which is actually inside SPIxBUF) to the output pin SDOx. As output bits are shifted out with each clock pulse, data on the input pin SDIx is shifted into SPIxRXB (also actually inside SPIxBUF). If 16-bit communication is being used, then after 8 clock pulses the SPIxBUF will consist of 8-bits of input data and 8-bits of output data. Once a full 16 clock pulses have happened, all of the SPIxTXB bits should have been shifted out and all the SPIxRXB bits received and inside the SPIxBUF. When all the bits have been written, the SPITBF flag (transmit buffer full) clears indicating that there are no more bits to write. Also, the SPIRBF flag (receive buffer full) should set indicating that bits have been shifted in.
Figure 1: SPI Module Register Diagram
If information has been received while the SPIxRXB is already full, the SPIROV (overflow bit) will set and the SPIRBF bit will supposedly not set. So in the read function, I checked to make sure that the SPIROV bit didn’t set, then would right a dummy byte to shift in input data, yet the SPIRBF bit would never set. This would cause the program to get stuck in the while () loop. I wasn’t able to resolve the problem after reading more about the SPI process to eliminate the possibility that the PIC was not reading data properly. I noted that even if the read function were reading data at the wrong time (before the ADC sent data over), the SPIxRXB buffer should be full of ON bits making (0xFFFF), since the ADC’s output pin is HIGH when idle. I thought this meant that some other module within the PIC33 must have been remapping the pin possibly preventing the SPI1 module from using it at all.
Figure 2: SPI1_read() function
